Technical debt (also known as design debt or code debt) are synonymous, neologistic metaphors referring to the eventual consequences of poor software architecture and software development within a codebase.
Common causes of technical debt include (a combination of):
"Interest payments" are both in the necessary local maintenance and the absence of maintenance by other users of the project. Ongoing development in the upstream project can increase the cost of "paying off the debt" in the future.
Best Practice in paying down technical debt is to refactor code as part of ongoing development.
"As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it."
— Meir Manny Lehman, 1980
While Manny Lehman's Law already indicated that evolving programs continually add to their complexity and deteriorating structure unless work is done to maintain it, Ward Cunningham first drew the comparison between technical complexity and debt in a 1992 experience report:
In his influential 2004 text, Refactoring to Patterns, Joshua Kerievsky presents a comparable argument concerning the costs associated with architectural negligence, which he describes as "design debt".[2]
Activities that might be postponed include documentation, writing tests, attending to TODO comments and tackling compiler and static code analysis warnings. Other instances of technical debt include knowledge that isn't shared around the organization and code that is too confusing to be modified easily.
In open-source software, postponing sending local changes to the upstream project is a technical debt.